Multimedia networks provide services above and beyond simple telephony. Thus, telephones no longer just transmit and receive telephone calls. Devices including cellular telephones, PDAs, laptop computers, and so on, collectively referred to as user equipment (UE), may transmit and receive telephone calls, may transmit and receive text messages, may participate in video-conferencing, may participate in multi-player gaming, may share content, and so on. These types of activities may be referred to collectively as multimedia services. In some cases these multimedia services may be provided over the Internet using the Internet Protocol (IP).
An IP Multimedia Core Network Subsystem (IMS) includes core network (CN) elements for providing IP multimedia services. These IP multimedia services may include telephony (e.g., Voice over IP (VoIP)), push to talk over cellular (PoC), text messaging, and so on. Within various services, other sub-services may be provided. For example, in the telephony service, sub-services including call forwarding, call waiting, voice mail, multi-party calling, and so on, may be provided. Conventionally, each of these services and/or sub-services may have been provided by a stand-alone electronic system, computer, and/or computer system. Various IMS components (e.g., switches) may be configured with information concerning a user on a per-session basis to facilitate connecting the user to services. Similarly, a component like an Application Server (AS) may be provided with information concerning the user to facilitate providing an authorized service for the user.
IMS defines how requests for service are routed to an AS that can provide the service. The routing may depend, at least in part, on information in a request. Thus, IMS components may be configured with information that describes how a request is to be evaluated and to which AS a request should be routed based on the evaluation. Conventionally, information concerning how to route messages may have been stored for each subscriber.
A user may access services via a dynamically associated, service-independent, standardized access point referred to as a call session control function (CSCF). A CSCF may be allocated dynamically to a user at log-on or when a request addressed to the user is received. To facilitate interacting with a user, a CSCF may acquire data (e.g., user data) that is more permanently stored in a Home Subscriber Server (HSS). The user data may include, for example, information that controls how a request is routed, information about which core network services a user is authorized to use, and so on.
Organizations with an IMS based communication network may store data concerning their network. These organizations may store data not only about their network (e.g., configuration) but also about the users (e.g., subscribers) who use the network, devices (e.g., CSCF) that participate in providing services, application servers that provide services, and so on. Conventionally, IMS networks may have used a large database that stored a record for each subscriber, with each record storing a large amount of diverse information. The database may have stored information including public and private user identities, services subscribed to, a service provided by an AS, a CSCF available to handle communications, CSCF capabilities, criteria for routing requests, and so on.
All this information may typically have been stored in large subscriber records. However, this may have created provisioning, updating, maintenance, and other issues for database systems administrators and network administrators. By way of illustration, consider an IMS with one million subscribers. The subscribers may use different services provided by different applications servers and may move from place to place while doing so. In this situation, when some information that may affect all the users changes, then conventionally one million user records would need to be updated. Additionally, each subscriber may have several sets of rules for how to route messages. Consider a situation where an IMS averages 15 sets of rules per user, 15 million sets of rules may need to be stored. This may be wasteful since many of the rules may be identical and thus duplicative.
Furthermore, consider an IMS having thousands of components (e.g., switches) that are configured with user information including routing criteria, authorized services, and so on. If information downloaded to one of these components changes, then a system administrator may need to locate the components in which the information was stored and update each of them. This may be undesirable and/or inefficient.
Additionally, adding and/or defining a user may create issues. For example, every user that is added or defined in the database may force the administrator to have to re-provision and define routing criteria, core services authorization data, and so on for the user. This creates many opportunities for errors as each record is individually provisioned.